Code Review中文译作“代码审查”或是“代码评审”,是一个流程,当开发人员写好代码后,需要让别人来review一下他的代码,这是一种有效发现BUG的方法。

通过Code Review可以审查代码的风格、逻辑、思路……,找出问题,以及改进代码。而且这是代码刚刚出炉的时候,所以,这也是代码重构,代码调整,代码修改的最佳时候。所以,Code Review是编码实现中最最重要的一个环节。

这个项目通过 githook 技术截获本机 git commit 命令,执行定制脚本,将本次代码的 diff log 以邮件方式发送给指定的团队成员,从而实现团队 Coding Review 流程,非常实用!

说明:

该项目教程共分为3个实验:

  • Git 钩子:定制工作流
  • Hook 实战:编写动作脚本
  • 使用 Hook 将代码版本变动信息通过邮件发送

这篇文章,介绍第1个实验 [ Git 钩子:定制工作流 ] ,文章内容全部截选自实验楼项目教程【使用 Githook 实现团队 Coding Review 流程】,如果想要查看完整教程,可以点击进入网站在线学习~

Git 钩子:定制工作流

概述:

Githook 也称 Git 钩子,是在 Git 仓库中特定事件发生时自动运行的脚本。它可以让你自定义 Git 内部的行为,在开发周期中的关键点出发自定义行为。

此处输入图片的描述

Git Hook 最常见的使用场景包括推行提交信息规范,根据仓库状态来改变项目环境,和接入持续集成工作流。但是因为脚本可以完全定制,你可以用 Git Hook 来自动化或者优化你开发工作流中任意部分。

Git Hook 是仓库中特定事件发生时 Git 自动运行的普通脚本。因此 Git Hook 安装和配置也非常容易。Hook 在本地或服务端仓库都可以部署,且只会在仓库中事件发生时被执行。在文章后面我们会具体地研究各种 Hook。

安装 Hook

Hook 存在与每个 Git 仓库的 .git/hooks 目录中。当你初始化仓库时,Git 自动生成这个目录和一些示例脚本。你可以在某个 .git/hooks 中,查看这些文件:

applypatch-msg.sample       pre-push.sample
commit-msg.sample           pre-rebase.sample
post-update.sample          prepare-commit-msg.sample
pre-applypatch.sample       update.sample
pre-commit.sample 
1
2
3
4
5

这里已经包含了大部分可用的 Hook 了,但是 .sample 拓展名防止它们默认被执行。为了安装一个 Hook ,你只需要去掉.sample 拓展名。或者你要写一个新的脚本,你只需添加一个文件名和上述匹配的新文件,去掉 .sample 拓展名。

比如尝试安装一个 prepare-commit-msg Hook 去掉 .sample 扩展名后在文件中写下这两行:

#!/bin/sh
echo "# Shiyanlou!" > $1 
1
2

Hook 如果想生效,需要对其修改文件权限,为了确保 prepare-commit-msg 可执行,运行下面这个命令:

chmod +x prepare-commit-msg 
1

接下来每次运行 git commit 的时候,你会发现默认的信息被替换了。

脚本语言

内置的脚本大多是 shell 和 perl 语言实现的,但你也可以使用任何脚本语言,只要它们最后能编译到可执行文件。每次脚本中#!/bin/sh 定义了你的文件将如何被解释。例如我们可以在 prepare-commit-msg中写一个可执行的 Python 脚本。下面这个 Hook 和上一节的 shell 脚本等效:

#!/usr/bin/env python

import sys, os

commit_msg_filepath = sys.argv[1]
with open(commit_msg_filepath, 'w') as f:
    f.write("# Please include a useful commit message!") 
1
2
3
4
5
6
7

注意:第一行改成了 Python 解释器的路径。此外sys.argv[1] 用来获取第一个参数。

钩子的作用域

对于任何 Git 仓库来说 Hook 都是本地的,而且它不会随着 git clone 一起复制到新的仓库。而且因为钩子是本地的,任何能接触到仓库的人都可以修改。对于开发团队来说,这有很大的影响。首先,你要确保你们成员之间的钩子都是最新的。其次,你也不能强行让其他人用你喜欢的方式提交——你只能鼓励他们这样做。

在开发团队中维护钩子是比较复杂的,因为 .git/hooks目录不随你的项目一起拷贝,也不受版本控制影响。一个简单的解决办法是把你的 Hook 存在项目的实际目录中(在 .git 外)。这样你就可以像其他文件一样进行版本控制。为了安装 Hook ,你可以在 .git/hooks 中创建一个符号链接,或者简单地在更新后把它们复制到 .git/hooks 目录下。

此处输入图片的描述

本地 Hook:

本地 Hook 只影响它们所在的仓库。以下是最常用的 6 个本地 Hook:

  • pre-commit
  • prepare-commit-msg
  • commit-msg
  • post-commit
  • post-checkout
  • pre-rebase

前四个 Hook 介入到版本提交的生命周期,后两个允许执行一些额外的操作,分别为 git checkout 和 git rebase 的安全检查。所有与带 pre- 的 Hook 代表即将发生的某个阶段,带 post- 只用于通知。

pre-commit

pre-commit 脚本在每次你运行 git commit 命令时,Git 向你询问提交信息或者生产提交对象时被执行。你可以用这个 Hook 来价差即将被提交的代码快照。比如说,你可以运行一些自动化测试,保证这个提交不会破坏现有的功能。

prepare-commit-msg

prepare-commit-msg这个 Hook 在 pre-commit Hook 在文本编辑器中生效提交信息之后被调用。prepare-commit-msg 的参数可以是下列三个:

  • 包含提交信息的文件名。你可以在原地更改提交信息。
  • 提交类型。可以是信息(-m 或 -F 选项),模板(-t选项),merge(如果是个合并提交)或squash(如果这个提交插入了其他提交)。
  • 相关提交的SHA1哈希字串。只有当-c,-C,或--amend选项出现时才需要。

post-commit

post-commit Hook 在 commit-msg Hook 之后立即被运行。它无法改变 git commit
的结果,主要用于通知。这里我们详细来讲述一下这个 Hook ,因为我们之后要用到它。

这个脚本没有任何参数,而且退出状态不会影响提交。对于大多数的 post-commit 脚本来说,你只是想访问你刚刚创建的提交。你可以用 git rev-parse HEAD来获得最近一次提交的 SHA1 哈希字符串,或者你可以用 git log -l HEAD 来获得完整的信息。

post-checkout

post-checkout Hook 和 post-commit Hook 很像,但它在你用 git checkout查看引用的时候被调用。

实验总结:

该实验学习了 Git Hook 来修改内部行为的原理,当仓库中特定的时间发生时接收消息。Hook 是存在与 git/hooks仓库中的普通脚本,因此也非常容易安装和定制。

关于后面两个实验内容:

  • Hook 实战:编写动作脚本
  • 使用 Hook 将代码版本变动信息通过邮件发送

点击【使用 Githook 实现团队 Coding Review 流程】,即可点查看完整的教程了~